Move this condition closer to where it's used.

I don't think this condition is quite right though. This condition is true when the user did not model any operation input structure. However, I think we want to assert that the body is empty when all of the operation input is bound to other parts of the HTTP message too. For example, with an operation input modeled like this:

structure MyOperationInput {
    @httpHeader("header")
    header: String
}

We also want to assert that the HTTP body is empty.

Add a protocol test to ensure we don't regress on this.

Also, this condition is wrong in that SyntheticInputTrait is only added when no operation input/output is modeled for an operation, but it is not if the operation input/output is modeled but is empty. See the documentation in OperationNormalizer.kt.

For example, consider the Healthcheck operation of the simple model:

@readonly
@http(uri: "/healthcheck", method: "GET")
@documentation("Read-only healthcheck operation")
operation Healthcheck {
    input: HealthcheckInputRequest,
    output: HealthcheckOutputResponse
}

@documentation("Service healthcheck output structure")
structure HealthcheckInputRequest {

}

@documentation("Service healthcheck input structure")
structure HealthcheckOutputResponse {

}

This model will make noInputs be false. Only with a:

operation Healthcheck {
}

will noInputs be true.

This is on purpose because of this test. It's the first example you give, but has a non-empty body and a content-type

Ah I see. Interesting. What's the protocol test that asserts that body must be empty when there is no modeled input? I can't seem to find it right now.

This one (which corresponds to the second example you give)

Why are we returning Ok(()) for protocols other than these two?

Is the plan to handle e.g. application/x-amz-json-1.0 for the AwsJson 1.0 protocol in a separate PR?

No, it's just that a client should always send an empty JSON object payload in AwsJson 1.0, so with {} in the body this would fail (this only checks whether the body is empty)

Ah, I see. Good callout. I think it's best then that we don't call this function in the codegen when we're generating AwsJson 1.x. Consider that we want to support custom protocols loaded from decorators, and that we would be performing this check for them inadvertently.

Since this check is now a protocol-specific concern, whether we perform or not this check should be up to the particular protocol implementation. So I would suggest that we add a method to the Protocol.kt interface that determines whether we should perform this check, and only call the function in the runtime when the protocol implementation of the interface returns true.

Also, this condition is wrong in that SyntheticInputTrait is only added when no operation input/output is modeled for an operation, but it is not if the operation input/output is modeled but is empty. See the documentation in OperationNormalizer.kt.

For example, consider the Healthcheck operation of the simple model:

@readonly
@http(uri: "/healthcheck", method: "GET")
@documentation("Read-only healthcheck operation")
operation Healthcheck {
    input: HealthcheckInputRequest,
    output: HealthcheckOutputResponse
}

@documentation("Service healthcheck output structure")
structure HealthcheckInputRequest {

}

@documentation("Service healthcheck input structure")
structure HealthcheckOutputResponse {

}

This model will make noInputs be false. Only with a:

operation Healthcheck {
}

will noInputs be true.

Ah, I see. Good callout. I think it's best then that we don't call this function in the codegen when we're generating AwsJson 1.x. Consider that we want to support custom protocols loaded from decorators, and that we would be performing this check for them inadvertently.

Since this check is now a protocol-specific concern, whether we perform or not this check should be up to the particular protocol implementation. So I would suggest that we add a method to the Protocol.kt interface that determines whether we should perform this check, and only call the function in the runtime when the protocol implementation of the interface returns true.

I don't want to block approval on this, but now that the prerequisite work has been done in #1698, it would be better to have this in the ServerProtocol implementations instead.

After this is merged I'll move this method in #1731